TITLE OF THE INVENTION 

REAL-TIME OS SIMULATOR 

BACKGROUND OF THE INVENTION 
5 Field of the Invention 

[0001] The present invention relates to real-time OS simulators 
used for developing application software incorporated in an 
embedded system. 

10 Description of the Background Art 

[0002] Embedded systems such as cellular phones and digital 
TVs incorporate application software which is unique to each of 
these systems. Such software for embedded systems is realized 
as multi-task software that is executed on a real-time operating 

15 system (OS) . The multi-task software is conventionally developed 
by using a software development system which is composed of a 
breadboard, ICE ( In Circuit Emulator ) , and other components . Such 
a system, which is hereinafter referred to as a real system, has 
to be prepared before software development, and therefore, the 

20 ■ amount of time for software development is reduced. Moreover, 
real systems may not be provided enough to all software developers 
as required. Furthermore, as the operating frequency of the real 
system rises, debugging by the ICE becomes difficult. 
[0003] One solution to the above problems is constructing, on 

25 a general-purpose personal computer or work station, a system which 

1 



is similar in operation to the real system and developing software 
for embedded systems by using the constructed system. In one method, 
a "real-time OS simulator" is used for relating a task in the real 
system to a thread in a general-purpose multi-thread OS 
5 (hereinafter referred to as general-purpose OS) and simulating 
the operation of a real-time OS. Such a real-time OS simulator 
can be easily realized by simulating multi-task capabilities of 
the real-time OS with the use of multi-thread capabilities which 
are provided by the general-purpose OS. Also, only developing 

10 a real-time OS simulator is enough for providing software 
development systems to software developers. Therefore, 
efficiency and reliability of software development can be increased. 
Hereinafter, the thread in this specification includes a "process" 
which is called in some general-purpose OSes. 

15 [0004] The real-time OS carries out a variety of processes such 
as task synchronization management, timer management, 
task-to-task communications, and memory management . Among these 
processes, to realize dispatch processing for switching running 
tasks and interrupt handling for calling an interrupt handler, 

20 the real-time OS uses hardware for real systems. The real-time 
OS simulator, on the other hand, cannot use such hardware and thus 
cannot carry out the dispatch processing and interrupt handling. 
[0005] The real-time OS carries out multi-level interrupt 
handling, in which an interrupt that has newly occurred in an 

25 interrupt handler may be handled first. Furthermore, the 



real-time OS carries out dispatch processing as required when 
called in a task or interrupt handler. When called in a task, 
the real-time OS immediately starts to carry out dispatch 
processing. When called in an interrupt handler, on the other 
5 hand, the real-time OS starts to carry out dispatch processing 
after returning from the interrupt handler (such processing is 
hereinafter referred to as delayed dispatch processing) . The 
above-described processes including delayed dispatch processing 
and multi-level interrupt handling as well as other capabilities 
10 of the real-time OS have to be simulated as closely as possible 
by the real-time OS simulator. 

[0006] FIG. 24 is a diagram showing the software configuration 
of a control software execution systemof a numerical control device 
that is disclosed in Japanese Patent Gazette No. 2820189. Note 

15 that FIG. 24 shows an abstract representation of the configuration 
without impairing the subject of the disclosed invention for easier 
comparison with the present invention. Four threads shown in FIG. 
2 4 run concurrently on a host computer which is equipped with a 
general-purpose OS . Of these threads, three threads 91 to 93 carry 

20 out the same processes as those which are realized by tasks running 
in the numerical control device that is separately provided from 
the host computer. The remaining thread, that is, a scheduler 
thread 90, regularly interrupts the threads 91 to 93, dynamically 
switching among the threads to run. According to this software 

25 execution system, the control software of the numerical control 



device can operate on the host computer. 

[0007] However, the scheduler thread 90 shown in FIG . 24 cannot 
serve as a real-time OS simulator for use in developing software 
for embedded systems. The reasons for this are described below. 
5 [0008] First, the scheduler thread 90 regularly interrupts the 
threads 91 to 93, carrying out preemptive control by dynamically 
switching among the threads to run. In the real system, on the 
other hand, non-preemptive task control is carried out, where the 
running task is switched when the task calls the real-time OS. 

10 The conventional method does not allow such non-preemptive task 
control, which is one of the characteristics of the real-time OS. 
[0009] Second, the scheduler thread 90 carries out the 
above-described thread control under the assumption that the 
general-purpose OS equally controls all threads. However, a 

15 thread scheduling algorithm of the general-purpose OS is generally 
not publicized. Also, some general-purpose OSes separately 
calculate thread priorities based on given thread priorities, and 
control thread running based on the calculated thread priorities . 
Such a general-purpose OS cannot control thread running only by 

20 setting the thread priorities by application software . Therefore, 
if the conventional method is implemented with such a 
general-purpose OS, only the threads 91 to 93 possibly run, and 
the scheduler' 90 does not run at all. 

[0010] Lastly, the scheduler thread 90 is not able to carry 
25 out interrupt handling which is required for the real-time OS 



simulator. Software for embedded systems operates in response 
to an interrupt that is externally provided. In the conventional 
method, however, such an interrupt cannot be handled. 



5 SUMMARY OF THE INVENTION 

[0011] Therefore, an object of the present invention is to 
provide a real-time OS simulator that closely simulates dispatch 
processing and interrupt handling which is carried out by a 
real-time OS, even on a general-purpose multi-thread OS using an 
10 arbitrary thread scheduling algorithm. 

[0012] The present invention has the following features to solve 
the above-described problems. 

[0013] A first aspect of the present invention is directed to 
a real-time OS simulator that assigns a task processing thread 
15 to run on a general-purpose multi-thread OS to each of a plurality 
of tasks to run on a real-time OS, and simulates an operation of 
the real-time OS on themulti-threadOS . The real-timeOS simulator 
comprises : 

a task switching instruction part for receiving a request 
20 that is issued from the task processing thread under the same 
conditions as in the real-time OS, and providing an instruction 
for switching the tasks in response to the received request; and 
a task switching thread for selecting and making one 
of the task processing threads run by suspending and resuming the 
25 task processing threads with capabilities of the multi-thread OS 



in cooperation with the task switching instruction part. 
[0014] As described above, in the first aspect, with the 
operations of the task switching instruction part and the task 
switching thread, only one task processing thread is selected for 
5 running. Thus, the dispatch processing in the real-time OS can 
be simulated irrespective of the thread scheduling algorithm which 
is provided by the multi-thread OS. 

[0015] According to a second aspect of the present invention, 
in accordance with the first aspect, the task switching instruction 

10 part selects a task processing thread to run next, provides the 
instruction for switching the tasks to the task switching thread, 
and then suspends the task processing thread that has issued the 
request. Further, in response to the provided instruction, the 
task switching thread resumes the selected task processing thread 

15 after a preceding running task processing thread is suspended. 
[0016] As described above, in the second aspect, the task 
switching thread resumes the task processing thread to run next 
after the preceding running task processing thread is suspended. 
Thus, only one task processing thread can enter a runnable state. 

20 [0017] In this case, in response to the instruction for 
switching the tasks which is provided by the task switching 
instruction part, the task switching thread may check, at 
predetermined intervals, whether the preceding running task thread 
is suspended or not. Thus, irrespective of the thread scheduling 

25 algorithm which is provided by the multi-thread OS, the task 



switching thread can run after the preceding running task 
processing thread is suspended. 

[0018] According to a third aspect of the present invention, 
in accordance with the first aspect, the task switching instruction 
5 part selects a task processing thread to run next, provides the 
instruction for switching the tasks to the task switching thread, 
and then sets the task processing thread that has issued the request 
in a waiting state. Further, in response to the provided 
instruction, the task switching thread suspends a preceding running 

10 task processing thread, and then releases the selected task 
processing thread from the waiting state for resuming. 
[0019] As described above, in the third aspect, after the task 
switching thread suspends the preceding running task processing 
thread, the task processing thread to run next is resumed. Thus, 

15 only one task processing thread can enter the runnable state. 
[0020] In the second or third aspect, the task switching 
instruction part may provide the instruction to the task switching 
thread after the task switching thread is enabled to start 
processing. Thus, a plurality of task processing threads do not 

20 simultaneously instruct the task switching thread to start 
processing . Therefore, the task switching thread can surely carry 
out dispatch processing. 

[0021] According to a fourth aspect of the present invention, 
in accordance with the first aspect, the task switching instruction 
25 part provides the instruction to the task switching thread after 



selecting a task processing thread to run next. Further, the task 
switching thread runs with a higher priority than the task 
processing threads and, in response to the instruction, suspends 
a preceding running task processing thread and then resumes the 
5 selected task processing thread. 

[0022] As described above, in the fourth aspect, if the 
multi-thread OS on which threads run according to specified 
priorities is used, the task switching thread runs with a higher 
priority than the task processing threads. Thus, only one task 

10 processing thread can enter the runnable state without requiring 
a waiting state for each task processing thread. 
[0023] According to a fifth aspect of the present invention, 
in accordance with the first aspect, an exception handling thread 
corresponding to task exception handling of each of the tasks and 

15 running on the multi-thread OS is further assigned to each of the 
tasks, and the task switching thread selects a thread to run next 
from among the task processing threads and the exception handling 
threads . 

[0024] As stated above, in the fifth aspect , one task processing 
20 thread and one exception handling thread are assigned to each task. 
The operations of the task switching instruction part and the task 
switching thread can control the running of these two types of 
thread, thereby simulating the task exception handling of the 
real-time OS. 

25 [0025] According to a sixth aspect of the present invention, 



in accordance with the first aspect, the real-time OS simulator 
further comprises an interrupt handling part for receiving an 
interrupt request which is issued by an interrupt thread that 
generates a pseudo- interrupt , suspending a running task processing 
5 thread, calling an interrupt handler corresponding to the interrupt 
request, and then selecting a task processing thread to run next 
for resuming. 

[0026] As stated above, in the sixth aspect, by using the 
interrupt handling part, the interrupt thread suspends the running 

10 task processing thread, and calls the interrupt handler. Thus, 
irrespective of the thread scheduling algorithm which is provided 
by the multi-thread OS, the interrupt handling and the delayed 
dispatch processing of the real-time OS can be simulated. 
[0027] In this case, when receiving the interrupt request from 

15 the interrupt thread while another interrupt thread is running, 
the interrupt handling part may suspend the running interrupt 
thread, call the interrupt handler corresponding to the interrupt 
request, and then resume the suspended interrupt thread. Thus, 
by using the interrupt handling part, the interrupt thread suspends 

20 the running interrupt thread and calls the interrupt handler 
corresponding to the subsequent interrupt, thereby simulating the 
multi-level interrupt handling of the real-time OS. 
[0028] Also, the interrupt thread may include a system clock 
interrupt thread that generates a pseudo-interrupt at 

25 predetermined time intervals. Thus, the timer management 



capability of the real-time OS can be simulated. 
[0029] According to a seventh aspect of the present invention, 
in accordance with the first aspect, the real-time OS simulator 
further includes a task processing thread creating part for 
5 creating the task processing thread, a thread creating part for 
creating the task processing thread and the exception handling 
thread, and/or an interrupt thread creating part for creating the 
interrupt thread. 

[0030] As stated above, in the seventh aspect, the simulator 

10 can create various threads by itself, simulating dispatch 
processing, task exception handling and interrupt handling. 
[0031] An eighth aspect of the present invention is directed 
to a computer-readable recording medium recording a program to 
run on a computer, where the program is for a simulation method 

15 of assigning a task processing thread to run on a general-purpose 
multi-thread OS to each of a plurality of tasks to run on a real-time 
OS and simulating an operation of the real-time OS on the 
multi-thread OS. The simulation method comprising the steps of: 
receiving a request which is issued from the task 

20 processing thread under the same conditions as the real-time OS 
and providing an instruction for switching the tasks in response 
to the received request; and 

selecting and making one of the task processing threads 
run by suspending and resuming the task processing threads with 

25 capabilities of the multi-thread OS. 



[0032] A ninth aspect of the present invention is directed to 
a program for a simulation method of assigning a task processing 
thread to run on a general-purpose multi-thread OS to each of a 
plurality of tasks to run on a real-time OS and simulating an 
5 operation of the real-time OS on the multi-thread OS. The 
simulation method comprising the steps of: 

receiving a request which is issued from the task 
processing thread under the same conditions as the real-time OS 
and providing an instruction for switching the tasks in response 
10 to the received request; and 

selecting and making one of the task processing threads 
run by suspending and resuming the task processing threads with 
capabilities of the multi-thread OS. 

[0033] These and other objects, features, aspects and 
15 advantages of the present invention will become more apparent from 
the following detailed description of the present invention when 
taken in conjunction with the accompanying drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 
20 [0034] FIG. 1 is a diagram showing the hardware construction 

of a computer system in which a real-time OS simulator according 

to a first embodiment of the present invention operates; 

FIG. 2 is a diagram showing the software configuration 

of the real-time OS simulator according to the first embodiment 
25 of the present invention; 

11 



FIG. 3 is a flowchart showing the main processing of 
the real-time OS simulator according to the first embodiment of 
the present invention; 

FIG. 4 is a flowchart showing the operation of a changer 
5 thread in the real-time OS simulator according to the first 
embodiment of the present invention; 

FIG. 5 is a flowchart showing the operation of a system 
function in the real-time OS simulator according to the first 
embodiment of the present invention; 
10 FIG. 6 is one exemplary timing chart showing dispatch 

processing which is carried out by the real-time OS simulator 
according to the first embodiment of the present invention; 

FIG. 7 is another exemplary timing chart showing the 
dispatch processing which is carried out by the real-time OS 
15 simulator according to the first embodiment of the present 
invention; 

FIG. 8 is still another exemplary timing chart showing 
the dispatch processing which is carried out by the real-time OS 
simulator according to the first embodiment of the present 
20 invention; 

FIG. 9 is a flowchart showing the operation of an 
interrupt handling function of the real-time OS simulator according 
to the first embodiment of the present invention; 

FIG. 10 is one exemplary timing chart showing interrupt 
25 handling of the real-time OS simulator according to the first 
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embodiment of the present invention; 

FIG. 11 is another exemplary timing chart showing the 
interrupt handling of the real-time OS simulator according to the 
first embodiment of the present invention; 
5 FIGS. 12A and 12B are other exemplary timing charts 

showing the interrupt handling of the real-time OS simulator 
according to the first embodiment of the present invention; 

FIG. 13 is still another exemplary timing chart showing 
the interrupt handling of the real-time OS simulator according 
10 to the first embodiment of the present invention; 

FIG. 14 is a flowchart showing the operation of a changer 
thread in a real-time OS simulator according to a second embodiment 
of the present invention; 

FIG. 15 is a flowchart showing the operation of a system 
15 function in the real-time OS simulator according to the second 
embodiment of the present invention; 

FIG. 16 is one exemplary timing chart showing dispatch 
processing which is carried out by the real-time OS simulator 
according to the second embodiment of the present invention; 
20 FIG. 17 is another exemplary timing chart showing the 

dispatch processing which is carried out by the real-time OS 
simulator according to the second embodiment of the present 
invention; 

FIG. 18 is an exemplary timing chart showing how tasks 
25 are switched by a real-time OS that supports task exception 
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processing; 

FIG. 19 is a diagram showing the software configuration 
of a real-time OS simulator according to a third embodiment of 
the present invention; 
5 FIG. 20 is a diagram showing the main processing of the 

real-time OS simulator according to the third embodiment of the 
present invention; 

FIG. 21 is a flowchart showing the operation of a changer 
thread in the real-time OS simulator according to the third 
10 embodiment of the present invention; 

FIG. 22 is flowchart showing an exception processing 
thread in the real-time OS simulator according to the third 
embodiment of the present invention; 

FIG. 23 is an exemplary timing chart of task exception 
15 processing which is carried out by the real-time OS simulator 
according to the third embodiment of the present invention; and 

FIG. 24 is a diagram showing the software configuration 
of a conventional control software execution system. 



20 DESCRIPTION OF THE PREFERRED EMBODIMENTS 

[0035] First Embodiment FIG. 1 is a diagram showing the 
hardware construction of a computer system in which a real-time 
OS simulator according to a first embodiment of the present 
invention operates. A computer 1 shown in FIG. 1 includes a CPU 

25 2, a timer circuit 3, a main memory 4, a hard disk 5, a keyboard 

14 



6, a mouse 7 , a display 8, and a communication port 9. The CPU 
2 transfers a program which is stored in advance in the hard disk 
5 to the main memory 4 for execution . The timer circuit 3 generates 
an interrupt signal at predetermined time intervals to be output 
5 to the CPU 2 . Following an instruction that is provided by a user 
through the keyboard 6 or the mouse 7, the computer 1 carries out 
a screen display on the display 8. The computer 1 also carries 
out data communications with other computers and components via 
the communication port 9. The computer 1 is equipped with a 

10 general-purpose multi-thread OS. Each thread that runs on the 
general-purpose OS can suspend or resume itself or another thread 
in arbitrary timing. Assume herein that the general-purpose OS 
has an event capability that enables each thread to generate a 
specific event or wait until a specific event occurs. 

15 [0036] FIG. 2 is a diagram showing the software configuration 
of the real-time OS simulator according to the first embodiment 
of the present invention. In a real system, a plurality of tasks 
run concurrently on the real-time OS, and a plurality of interrupts 
occur asynchronously. In a real-time OS simulator 10, one task 

20 in the real system is related to one thread that runs on the 
general-purpose OS (hereinafter referred to as a task processing 
thread) . Similarly, one interrupt in the real system is related 
to one thread that runs on the general-purpose OS (hereinafter 
referred to as an interrupt thread) . 

25 [0037] In the real-time OS simulator 10 of FIG. 2, exemplarily 



shown are first to third task processing threads 21 to 23 which 
correspond to three tasks and first to third interrupt threads 
31 to 33 which correspond to three interrupts, where all of the 
threads are running concurrently. Each of the task processing 
5 threads 21 to 23 calls each different task function that actually 
carries out the task work in the real system. In some cases, the 
task processing thread calls a debugging-purpose input/output 
function (I/O function) for carrying out an input/output to/from 
a storage or I/O device in the computer 1 . For example, by calling 
10 I/O functions which are supported by the real-time OS, the task 
processing thread reads data from the hard disk 5, or causes the 
display 8 to display the data. 

[0038] The interrupt threads 31 to 33 each generate a 
pseudo-interrupt so as to simulate an interrupt in the real system. 

15 Each interrupt thread includes an interrupt handler that 
corresponds to the interrupt. When a pseudo-interrupt is being 
generated, the pseudo-interrupt is given (inputted) by an input 
device of the computer 1 or the like, and is supplied to each 
interrupt thread through the capabilities of the general-purpose 

20 OS. For example, the pseudo-interrupt is generated when a timer 
interrupt is generated by the timer circuit 3, when a user operates 
the keyboard 6 or the mouse 7, or when data is transmitted and/or 
received through the communication port 9 . In the first embodiment , 
assume that the third interrupt thread 33 is a systemclock interrupt 

25 thread for causing a pseudo-interrupt that corresponds to a system 
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clock interrupt. 

[0039] The real-time OS simulator 10 includes a changer thread 
11, system functions 12, interrupt handling functions 13, and a 
system clock interrupt thread 33 . The system function 12 is called 
5 from the corresponding one of the task processing threads 21 to 
23 in the same manner as when the real-time OS is called from the 
task in the real system. The interrupt handling function 13 is 
called when the corresponding one of the interrupt threads 31 to 
33 generates a pseudo-interrupt . The changer thread 11 runs 

10 concurrently with the task processing threads 21 to 23 and the 
interrupt threads 31 to 33. The changer thread 11, the system 
functions 12, and the interrupt handling functions 13 call a thread 
suspend/resume capability and event capability, as will be 
described below, thereby controlling the running of threads. 

15 [0040] The real-time OS simulator 10 is transferred, together 
with the task functions and the interrupt handlers, to the main 
memory 4, and is executed by the CPU 2. Thus, the task processing 
threads 21 to 23 corresponding to the tasks in the real system 
can carry out data input/output to/from the hard disk 5 and the 

20 display 8. Moreover, the pseudo-interrupt can occur while the 
task processing threads are running. As such, by executing the 
software shown in FIG. 2 on the computer 1 shown in FIG. 1, the 
user can debug the task functions and the interrupt handlers which 
are included in the application software in the real system. 

25 [0041] Hereinafter, the software configuring the real time OS 



simulator 10 will be described in detail. FIG. 3 is a flowchart 
showing the main processing of the real-time OS simulator 10. The 
real-time OS simulator 10 is given, in advance, task functions 
corresponding to the tasks in the real systemand interrupt handlers 
5 also in the real system. First, the real-time OS simulator 10 
creates the changer thread 11 and the system clock interrupt thread 
33 (steps S101, S102) . Then, the real-time OS simulator 10 
sequentially creates task processing threads corresponding to the 
given task functions (steps S103, S104) . Then, the real-time OS 

10 simulator 10 enables an interrupt from the interrupt thread (step 
S105) , and thereafter repeats sleeping (stand-by) for a 
predetermined time (step S106) . After step S106 is performed, 
the seven threads shown in FIG. 2 start to run concurrently. The 
subsequent capabilities of the real-time OS simulator 10 are 

15 realized by the changer thread 11, the system functions 12, and 
the interrupt handling functions 13. 

[0042] The real-time OS simulator lOmainly operates as follows . 
For switching to the next task at the time of calling the system 
function 12, each of the task processing threads 21 to 23 selects 

20 the task processing thread to run next , instructs the changer thread 
11 to start dispatch processing, and then suspends itself. The 
interrupt threads 31 and 33 run concurrently with other threads, 
calling the interrupt handling function 13 when causing a 
pseudo-interrupt . The interrupt thread that calls the interrupt 

25 handling function 13 suspends the currently running thread, and 
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records itself as the running thread. Thereafter, the interrupt 
thread calls the corresponding interrupt handler, and then selects 
the thread to run next for resuming. In order to establish 
synchronization among the threads, two types of events are utilized 
5 A first event is for the task processing threads 21 to 23 to instruct 
the changer thread 11 to start dispatch processing . A second event 
is for the changer thread 11 and the interrupt threads to notify 
the other threads that dispatch processing and interrupt handling 
are now enabled to start. 

10 [0043] FIG. 4 is a flowchart showing the operation of the changer 
thread 11 . The changer thread 11 first sets the second event (step 
S201), and then repeats the processing from steps S202 thorough 
S207 . The changer thread 11 enters the waiting state for the first 
event that instructs the changer thread 11 to start dispatch 

15 processing (stepS202) . After the first event is set , the procedure 
goes to step S203. The changer thread 11 then repeats sleeping 
for a predetermined time until the running task processing thread 
is suspended (steps S203, S204). Thus, it is ensured that the 
changer thread 11 does not run while the task processing thread 

20 is running . After the running task processing thread is suspended, 
the changer thread 11 records the task processing thread which 
is selected to run next as the running thread (step S205), and 
resumes the selected task processing thread (step S206) . The 
changer thread 11 then sets the second event indicating that 

25 dispatch processing and interrupt handling are enabled to start 
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(step S207) . The procedure then returns to step S202. 
[0044] FIG. 5 is a flowchart showing the operation of the system 
function 12 which is called from the task processing thread. The 
task processing thread which called the system function carries 
5 out any processing that is provided by the real-time OS except 
thread dispatching processing (step S301) . For example, in task 
switching processing in the real-time OS, the running task is moved 
to the tail of a runnable task queue, and the task which is located 
at the head thereof is changed to the running state. 

10 Correspondingly, the processing similar to that in step S301 is 
also carried out in the real-time OS simulator 10. Then, the task 
processing thread determines whether dispatch processing should 
be carried out or not as a result of the processing in step S301 
(step S302). If the task processing thread determines that 

15 dispatch processing should be carried out, the task processing 
thread carries out steps S303 to S305. 

[0045] If dispatch processing should be carried out, the task 
processing thread first enters the waiting state for the second 
event, waiting until the changer thread 11 is enabled to start 

20 dispatch processing (step S303) . After the changer thread 11 is 
enabled to start the dispatch processing, the task processing 
thread sets the first event that instructs the changer thread 11 
to start the dispatch processing (step S304) , and suspends itself 
(step S305) . Thus, the task processing thread is suspended in 

25 step S305 and thereafter, and the changer thread 11 runs. 



[0046] FIGS. 6 to 8 are exemplary timing charts of dispatch 
processing which is carried out by the real-time OS simulator 
according to the first embodiment. In these timing charts, each 
line in the horizontal direction represents one thread. A thick 
5 line represents that the thread is in a running state; a narrow 
line represents that the thread is in a runnable state; and a broken 
lines represents that the thread is in a suspended or waiting state . 
# represents calling the system function; A represents setting 
an event; A represents waiting for an event; □ represents 
10 suspending the thread; I represents resuming the thread; and ♦ 
represents recording the running thread. 

[0047] FIG. 6 is one exemplary timing chart of dispatch 
processing corresponding to the switching from a first task to 
a second in the real system. Assume that, in the initial state, 

15 the changer thread is in the waiting state for the first event 
(step S202) , and a first task processing thread is running. The 
first task processing thread calls the system function at a time 
tl, and then carries out processing except for dispatch processing 
between the time tl and a time t2 (step S301) . The first task 

20 processing thread then determines that dispatch processing should 
be carried out (step S302) , and enters the waiting state for the 
second event at the time t2 (step'S303) . Until then, the second 
event has been set, and therefore, the procedure immediately goes 
to step S304, wherein the first task processing thread sets the 

25 first event at a time t3. With this, the changer thread enters 
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the runnable state after the time t3. 

[0048] In the timing chart shown in FIG . 6, the first task thread 
runs continuously, and suspends itself at a time t4 (step S305) . 
When the first task processing thread is suspended at the time 
5 t4, the changer thread records, atatimet5, a second taskprocessing 
thread as the running thread (step S205), and resumes the second 
task processing thread at a time t6 (step S206) . Therefore, the 
second task processing thread is in the runnable thread after the 
time t6. The changer thread sets the second event at a time t7, 

10 and notifies the other threads that dispatch processing is enabled 
to start (step S207) . Then, the changer thread enters the waiting 
state for the first event at a time t8 (step S202) . Therefore, 
the second task processing thread runs after the time t8 . As such, 
dispatching processing from the first task processing thread to 

15 the second is carried out . The time which is required for dispatch 
is between the time t2 and the time t7, as indicated by a period 
T in FIG. 6. 

[0049] In the timing chart shown in FIG. 6, two threads are 
simultaneously in the runnable state between the time t3 and the 

20 time t4 and between the time t6 and the time t8. In this case, 
the thread from among the two which is to run depends on the thread 
scheduling algorithm that is provided by the general-purpose OS. 
[0050] FIG . 7 is another exemplary timing chart when the changer 
thread runs after the time t3. In this case, the changer thread 

25 repeats sleeping for a predetermined time until the running task 
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processing thread is suspended (steps S203, S204). The changer 
thread enters a sleep state at a time t3-l and, thereafter, the 
first task processing thread runs again . The first task processing 
thread suspends itself at the time t4 (step S305) . The changer 
5 thread then comes out from the sleep state at a time t4-l, and 
carries out steps S205 through S207. Therefore, the timing chart 
after the time t4-l shown in FIG. 7 coincides with that shown in 
FIG. 6. As such, the changer thread repeats sleeping until the 
running task processing thread is suspended. Therefore, the 
10 dispatch processing in the real-time OS can be simulated 
irrespective of the thread scheduling algorithm that is provided 
by the general-purpose OS. 

[0051] FIG. 8 is still another exemplary timing chart 
illustrating when the second task processing thread runs after 

15 the time t6. The timing chart from the initial state to the time 
t6 shown in FIG. 8 coincides with that shown in FIG. 6. The second 
task processing thread which is resumed at the time t6 calls the 
system function at a time t6-l, and then enters the waiting state 
for the second event at a time t6-2 (step S303) . Therefore, the 

20 changer thread runs again, and sets the second event at a time 
t7 (step S207) . As such, the use of the event capability which 
is provided by the general-purpose OS prevents a plurality of task 
processing threads from simultaneously instructing the changer 
thread to carry out dispatch processing. Therefore, the changer 

25 thread can surely carry out dispatch processing. 



[0052] FIG. 9 is a flowchart showing the operation of the 
interrupt handling function 13 that is called from the interrupt 
thread. The interrupt thread that called the interrupt handling 
function first enters the waiting state for the second event, 
5 waiting until the changer thread is enabled to start interrupt 
handling (stepS401) . After the changer thread is enabled to start 
interrupt handling, the interrupt thread suspends the running 
thread (step S402) . The thread to be suspended in step S402 is 
either any task processing thread or any other interrupt thread. 

10 The interrupt thread then records itself as the running thread 
(step S403) . The interrupt thread then sets the second event, 
and notifies the other threads that the interrupt handling is 
enabled to start (step S404) . The interrupt thread then calls 
the interrupt handler corresponding to its own interrupt (step 

15 S405) . 

[0053] After the processing of the interrupt handler ends, the 
interrupt thread checks whether multi-level interrupt handling 
and delayed dispatch processing should be carried out (steps S406, 
S407) . If delayed dispatch processing should be carried out but 

20 multi-level interrupt handling should not be carried out, the 
interrupt thread records the task processing thread to run next 
as the running thread (step S408), and resumes that thread (step 
S409) . Otherwise, the interrupt thread records the thread which 
is suspended in step S402 as the running thread (step S410) , and 

25 resumes that thread (step S411) . 



[0054] FIGS. 10 through 13 show exemplary timing charts of 
interrupt handling which is carried out by the real-time OS 
simulator according to the first embodiment. FIGS. 10 through 
13 are illustrated with the same notation as that in FIG. 6. 
5 [0055] FIG. 10 is one exemplary timing chart illustrating a 
case where a first interrupt occurs while the first task processing 
thread is running. Assume that, at the initial state, the second 
event has been set and the first task processing thread is running. 
Also assume that the first interrupt thread is in the runnable 

10 state at the initial state, and calls for the interrupt handling 
function at the time tl . After the time tl, the first interrupt 
thread operates by following the flowchart shown in FIG . 9 . First, 
the first interrupt thread enters the waiting state for the second 
event at the time t2 (step S401) . Until then, the second event 

15 has been already set, and therefore, the procedure immediately 
goes to step S402, wherein the first interrupt thread suspends, 
atthetimet3, the running thread, thatis, the first taskprocessing 
thread (step S402) . Therefore, the first task processing thread 
is in a suspended state . 

20 [0056] Then, the first interrupt thread records itself as the 
running thread at the time t4 (step S403), and sets the second 
event at the time t5 (step S404) . Therefore, any other interrupt 
handling is enabled to start after the time t5. Furthermore, the 
first interrupt thread calls the interrupt handler corresponding 

25 to its own interrupt between the time t6 and the time tl (step 



S405) . The first interrupt thread then determines that neither 
multi- level interrupt handling nor the delayed dispatch processing 
should be carried out (steps S406, S407) . The procedure then goes 
to step S410. Finally, the first interrupt thread records, at 
5 the time t8, the first task processing thread which is suspended 
in step S402 as the running thread (step S410) , and resumes that 
thread at the time t9 (step S411) . Thus, the first task processing 
thread runs again. As such, the interrupt thread that called the 
interrupt handling function suspends the running task processing 
10 thread, and resumes the suspended task processing thread after 
calling the interrupt handler . Therefore, the interrupt handling 
of the real-time OS can be simulated. 

[0057] FIG. 11 is an exemplary timing chart of delayed dispatch 
processing. The timing chart between the initial state and the 

15 time t7 shown in FIG. 11 coincides with that shown in FIG. 10. 
For the delayed dispatch processing, the procedure goes from step 
S407 to step S408. Then, the first interrupt thread records, at 
the time t8, the second task processing thread as the running thread 
(step S408) , and resumes that thread at the time t9 (step S409) . 

20 Thus, after the time t9, the second task processing thread runs 
instead of the first task processing thread. As such, by resuming 
the task processing thread except for the suspended one, the delayed 
dispatch processing of the real-time OS can be simulated. 
[0058] FIGS. 12A and 12B show exemplary timing charts of 

25 multi-level interrupt handling. The timing chart shown in FIG. 



12A is followed by that shown in FIG. 12B in time. The timing 
chart between the initial state and a time t6-l shown in FIG. 12A 
coincides with that shown in FIG. 10. After the interrupt thread 
notifies the other threads, at the time t5, that the interrupt 
5 handling is enabled to start, assume that the second interrupt 
thread calls the interrupt handling function at the time t6-l. 
The second interrupt thread suspends, at a time t6-3, the preceding 
running thread, that is, the first interrupt thread (step S402), 
and carries out the processing from steps S403 through S405 between 

10 the time t6-3 and a time t6-7. The second interrupt thread then 
determines that themulti-level interrupt handling is being carried 
out (step S406) , and the procedure then goes to steps S406 to S410. 
Finally, the second interrupt thread records, at a time t6-8, the 
first interrupt thread as the running thread (step S410) , and 

15 resumes that thread at a time t6-9 (step S411) . Thereafter, the 
resumed first interrupt thread operates similar to a case where 
an interrupt from the second interrupt thread does not occur. As 
such, if one interrupt thread is running when another interrupt 
occurs, the interrupt thread is suspended, and the interrupt 

20 handler corresponding to the subsequent interrupt is called. 
Therefore, the multi-level interrupt handling of the real-time 
OS can be simulated. 

[0059] FIG. 13 is an exemplary timing chart of interrupt 
handling when an interrupt occurs while dispatch processing is 
25 being carried out. This timing chart exemplifies a case where 
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the first interrupt thread calls the interrupt handling function 
at the time t4 in FIG . 6. The first interrupt thread enters the 
waiting state for the second event at a time t4-l (step S401) . 
Therefore, the changer thread runs after the time t4-l. The first 
5 interrupt thread enters the runnable state after the changer thread 
sets the second event at the time t7, and then runs after the changer 
thread enters the waiting state for the first event. As such, 
with exclusive control by using the second event, the interrupt 
handling during dispatch processing in the real-time OS can be 
10 simulated. 

[0060] The system clock interrupt thread 33 generates a 
pseudo-interrupt corresponding to a system clock, and includes 
an interrupt handler that handles a system clock interrupt. With 
such an interrupt thread, timer management capability of the 

15 real-time OS in the real system can be simulated. 

[0061] As stated above, in the real-time OS simulator according 
to the first embodiment, the task processing thread selects, when 
calling the system function, the task processing thread which is 
to run next, instructs the changer thread to start dispatch 

20 processing, and then suspends itself. The changer thread, on the 
other hand, when instructed to start the processing, suspends the 
preceding running task processing thread and then resumes the 
selected task processing thread to be processed next. Thus, the 
dispatch processing of the real-time OS can be simulated 

25 irrespective of the thread scheduling algorithm which is provided 
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by the general-purpose OS. Moreover, the task processing thread 
instructs the changer thread to start processing after the changer 
thread is enabled to start dispatch processing, thereby preventing 
a plurality of task processing threads from simultaneously 
5 instructing dispatch processing . Still further, when calling the 
interrupt handling function, the interrupt thread suspends the 
running thread, calls the interrupt handler that corresponds to 
the task processing thread to run next, and then resumes the task 
processing thread. Thus, the interrupt handling and the delayed 

10 dispatch processing of the real-time OS can be simulated. Still 
further, also when an interrupt occurs while the interrupt thread 
is running, the interrupt thread suspends the running interrupt 
thread, and resumes the suspended interrupt thread after calling 
the interrupt handler corresponding to the subsequent interrupt. 

15 Thus, the multi-level interrupt handling in the real-time OS can 
be simulated. As such, the real-time OS simulator according to 
the first embodiment can simulate the capabilities of the real-time 
OS which are required for developing multi-task software to run 
on the real-time OS. 

20 [0062] Second Embodiment 

A real-time OS simulator according to a second embodiment 
of the present invention has the same software configuration as 
that of the real-time OS simulator according to the first embodiment, 
except for the changer thread and part of the system functions. 

25 The real-time OS simulator according to the second embodiment also 
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operates on a general-purpose OS that prohibits the thread from 
suspending itself . This real-time OS simulator uses a third event 
which is provided for each task processing thread and indicating 
that the task processing thread is in the waiting state. 
5 [0063] FIG. 14 is a flowchart showing the operation of the 
changer thread 11 according to the second embodiment. As shown 
in FIG. 4, the changer thread according to the first embodiment 
repeats sleeping for the predetermined time until the running task 
processing thread is suspended (steps S203, S204) . The changer 
10 thread according to the second embodiment, on the other hand, is 
characterized as suspending the running task processing thread 
(step S503) . 

[0064] In the flowchart shown in FIG. 14, the processing except 
for steps S503 to S505 are the same as that shown in FIG. 4, and 

15 are therefore not described here. After the first event 
instructing the changer thread to start dispatch processing is 
set (step S502), the changer thread suspends the running task 
processing thread (stepS503) . The changer thread then determines 
whether the task processing thread to run next is suspended by 

20 the delayed dispatch processing due to interrupt (step S504) . If 
the charger thread determines that the task processing thread to 
run next is suspended by the delayed dispatch, the third event 
concerning the task processing thread to run next is set (step 
S505) . 

25 [0065] FIG. 15 is a flowchart showing the operation of the system 



function 12 which is called from the task processing thread. The 
processing from steps S601 through S604 in FIG. 15 is the same 
as that from steps S301 through S304 in the flowchart shown in 
FIG. 5, and therefore is not described here. The task processing 
5 thread that has called the system function enters, in step S605, 
the waiting state for the third event concerning its own thread. 
[0066] As such, the task processing thread first instructs the 
changer thread to start the processing, and then enters the waiting 
state for the third event. When instructed as the above, the 
10 changer thread suspends the running task processing thread. 
Therefore, the dispatch .processing of the real-time OS can be 
simulated even when a general-purpose multi-thread OS prohibiting 
a thread from suspending itself is used. 

[0067] FIGS. 16 and 17 are exemplary timing charts of dispatch 
15 processing which is carried out by the real-time OS simulator 
according to the second embodiment. The timing charts in FIGS. 
16 and 17, which are illustrated with the same notation as that 
in FIG. 6, correspond to those illustrated in FIGS. 6 and 7, 
respectively. Assume herein that the second event has been set 
20 at the initial state. Also assume that the changer thread is in 
the waiting state for the first event (step S502), and that the 
second task processing thread is in the waiting state for the third 
event within the system function (step S605) . 

[0068] In the timing chart of FIG. 16, the first task processing 
25 thread calls the system function at the time tl, sets the first 
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event at the time t3 (step S604) , and then enters the waiting state 
for the third event at a time t3-l (step S605) . This causes the 
changer thread to run at the time t3-l . The changer thread suspends 
the first task processing thread at the time t4 (step S503) . The 
changer thread then determines whether the task processing thread 
to run next has been suspended by the delayed dispatch processing 
(step. S504). In this example, the procedure goes to from step 
S504 to step S505, wherein the changer thread sets the third event 
concerning the second task processing thread at a time t4-l (step 
S505) . This causes, at the time t4-l, the second task processing 
thread to come out from the waiting state for the third event and 
then to be suspended. The changer thread then, at the time t5, 
records the second task processing thread as the thread to run 
next (step S506) , and resumes the second task processing thread 
at the time t6 (step S507 ) . This causes the second task processing 
thread to be in the runnable state after the time t6 . Furthermore, 
the changer thread sets the second event at the time t7 (step S508) , 
and then enters the waiting state for the first event (step S502) . 
This causes the second task processing thread to run at the time 
t8. 

[0069] FIG. 17 is an exemplary timing chart illustrating when 
the changer thread runs after the time t3. This timing chart is 
different from that of FIG. 16 only in that the changer thread 
suspends the first task processing thread at the time t4 (step 
S503) . 
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[0070] Note that, in the timing charts of FIGS. 16 and 17, if 
the second task processing is not in the waiting state for the 
third event, the procedure goes from step S504 to step S506, and 
the changer thread does not set the third event concerning the 
5 second task processing thread. 

[0071] As stated above, in the real-time OS simulator according 
to the second embodiment, the task processing thread instructs 
the changer thread to start the processing, and then enters the 
waiting state. When instructed as the above, the changer thread 

10 suspends the running task processing thread, and then releases 
the suspended running task processing thread, if the task 
processing thread to run next is in the waiting state, from the 
waiting state for resuming. Therefore, the dispatch processing 
of the real-time OS can be simulated even when a general-purpose 

15 multi-thread OS prohibiting a thread from suspending itself is 
used . 

[0072] Note that, if a general-purpose multi-thread OS on which 
threads run according to specif ic priorities is used, the scheduler 
thread may be given a higher priority to the task processing thread. 

20 In this case, even if the processing for the third event is deleted 
from the flowcharts shown in FIGS. 14 and 15, the scheduler thread 
runs prior to the task processing thread, thereby achieving the 
same effects of the second embodiment. 
[0073] Third Embodiment 

25 A real-time OS simulator according to a third embodiment 
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of the present invention is constructed by adding a capability 
of simulating task exception handling to the real-time OS simulator 
according to the first embodiment. The task exception handling 
is a capability of handling an exception which has occurred on 
5 a task in its context, and adopted by m IT RON (Micro Industrial 
The Real-time Operating System Nucleus) Ver. 4.0. In a real-time 
OS supporting such task exception handling, an exception handler 
is defined for each task, and each task can request any other task 
to carry out task exception handling. The task which is requested 
10 to carry out task exception handling suspends the running 
processing, and executes the task exception handler in the same 
context as that of the suspended processing. 

[0074] FIG. 18 is an exemplary timing chart showing how tasks 
are switched by the real-time OS that supports task exception 

15 handling. In FIG. 18, a horizontal line represents one task. A 
thick line represents that the task is executing normal processing; 
a double line represents that the task exception handling is being 
executed; and a broken line represents that the task is being 
suspended . Ablankportion represents that the taskdoes not exist . 

20 O represents that the system function which affects task switching 
is called. Note that a higher priority is given to the first task, 
a lower priority is given to the second task, and even lower priority 
is given to the third task. 

[0075] In the real-time OS that supports task exception handling, 
25 task switching is carried out as follows. When the user provides 
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an instruction input for starting processing, a first task waiting 
for an input from the user creates a second task carrying out lower 
processing, and then again enters the waiting state for an input 
from the user. The second task creates a third task carrying out 
5 further lower processing, and then enters the waiting state for 
the third task to exit or the waiting state for the processing 
to be canceled. When an instruction for canceling is provided 
while the third task is running, the first task instructs the second 
task to cancel the processing, and comes out from the waiting state 

10 for the second task. Then, the first task carries out task 
exception handling, and then enters the waiting state for the second 
task to exit. Requested to carry out task exception handling, 
the second task further requests, within the exception handler 
of its own, the third task to carry out task exception handling, 

15 and enters the waiting state for the third task to exit. Requested 
to carry out task exception handling, the third task carries out, 
within the exception handler of its own, memory deallocation and 
other processing, and then exits. When the third task exits, the 
second task exits. As a result, the first task processing 

20 thereafter runs . As such, by suspending the task by task exception 
handling, needless processing can be eliminated, and the efficiency 
of the real system can be improved. 

[0076] FIG. 19 is the software configuration of the real-time 
OS simulator according to the third embodiment of the present 
25 invention. As shown in FIG. 19, a real-time OS simulator 40 



includes a changer thread 41, system functions 42, exception 
handling functions 43, and interrupt handling functions 13. In 
the real-time OS simulator 40, each task in the real system is 
related to two threads (a task processing thread and an exception 
5 handling thread) to run on a general-purpose OS. Of these two 
threads , the exception handling thread is the one which is provided 
in the third embodiment for simulating task exception handling 
of the real-time OS . The interrupt handling in the third embodiment 
is the same as that in the first embodiment. Therefore, in the 
10 third embodiment, the same components as those in the first 
embodiment are provided with the same reference numerals, and are 
not described herein. 

[0077] FIG. 19 exemplarily shows the real-time OS simulator 
40, wherein three tasks correspond to first to third task processing 

15 threads 51 to 53 and first to third exception handling threads 
61 to 63 , and three interrupts correspond tofirstto third interrupt 
threads 31 to 33. All of these threads run concurrently. As 
described above, each task in the real system corresponds to one 
task processing thread and one exception handling thread. For 

20 example, the first task in the real system corresponds to the first 
task processing thread 51 and the first exception handling thread 
61. 

[0078] FIG. 20 is a flowchart showing the main processing of 
the real-time OS simulator 40. In the flowchart shown in FIG. 
25 20, the processing except for step S705 is the same as that in 
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FIG. 3, and therefore is not described herein. In addition to 
the task functions and the interrupt handlers, the real-time OS 
simulator 40 is provided with exception handlers for the tasks. 
These exception handlers are the same as those which are called 
5 when task exception handling is requested in the real system. The 
real-time OS simulator 40 creates, every time the real-time OS 
simulator 40 creates the task processing thread corresponding to 
a task (step S704) , the exception handling thread for calling the 
exception handler for that task (step S705) . After step S707, 

10 all of those ten threads shown in FIG. 19 start to run concurrently. 
[0079] For simulating task exception handling, the real-time 
OS simulator 40 uses three flags, that is, an exception handling 
request flag, an exception handling enable flag, and an exception 
handling state flag. The exception handling request flag 

15 indicates whether task exception handling is requested for the 
task or not . The exception handling enable flag indicates whether 
task exception handling is enabled for the task or not. The 
exception handling state flag indicates whether the task is 
executing task exception handling or not. The exception handling 

20 request flag and the exception handling enable flag are set in 
the system function 42 and the exception handling function 43, 
while the exception handling state flag is set in the exception 
handling thread. The changer thread 41 refers to these flags to 
select the thread to run next. 

25 [0080] The task processing threads 51 to 53 each execute normal 



task processing similar to the first embodiment. The system 
function 42 is called from each of the task processing threads 
51 and 53 in a manner similar to when the real-time OS is called 
from the task in the real system. The system function 42 according 
5 to the third embodiment is characterized as including task 
exception handling functions that can be called in a manner similar 
to that in the real-time OS. The flowchart of the operation of 
the system function 42 is the same as that shown in FIG. 5. The 
above three flags are set in step S301 of FIG. 5. For example, 

10 the exception handling request flag is set ON in step S301 of a 
function for requesting task exception handling. The exception 
handling enable flag is set ON in step S301 of a function for enabling 
task exception handling, and is set OFF in step S301 of a function 
for disabling task exception handling. 

15 [0081] FIG. 21 is a flowchart showing the operation of the 
changer thread 41. In the flowchart of FIG. 21, the processing 
except for steps S805 to S808 is the same as that in FIG. 4, and 
therefore is not described herein. After all task processing 
threads andexceptionhandling threads are suspended, theprocedure 

20 goes to step S805 (step S803) . Until then, the task to run next 
(hereinafter referred to as a next task) has been determined by 
the processing except for the dispatch of the system function 42 
(step S301) . If the exception handling state flag or the exception 
handling request flag is ON (steps S805, S806) , the changer thread 

25 41 selects the exception handling thread corresponding to the next 



task as the thread to run next (step S808) . Otherwise, the changer 
thread 41 selects the task processing thread corresponding to the 
next task as the thread to run next (step S807) . Note that, if 
the exception handling enable flag is OFF in step S8 06, the procedure 
5 goes to step S807. As such, the changer thread 41 selects one 
of the two threads corresponding to the next task as the thread 
to run next. 

[0082] The exception handling threads 61 to 63 each call the 
exception handler for the task to execute task exception handling. 

10 The real-time OS simulator 4 0 includes the exception handling 
functions 43 for carrying out the main processing of the exception 
handling threads 61 to 63. FIG. 22 is a flowchart of the main 
processing (that is, the exception handling function 43) in the 
exception handling thread. The main processing is the same among 

15 the exception handling threads 61 to 63 except that the exception 
handler to run in step S904 varies according to the task. 
[0083] The exception handling thread suspends itself 
immediately after being created (step S901) . When resumed by the 
changer thread, the exception handling thread sets its exception 

20 handling state flag ON, thereby indicating that task exception 
handling is being executed (step S902) . Then, the exception 
handling thread sets its exception handling request flag from ON 
to OFF (step S902) . Then, the exception handling threads calls 
the exception handler of its own (step S904) . In the exception 

25 handler, predetermined processing that varies for each task is 



carried out. When returning from the exception handler, the 
exception handling thread sets its exception handling state flag 
OFF, thereby indicating- that the task exception handling is not 
being executed (step S905) . 
5 [0084] In some cases, while the exception handling thread is 
executing the exception handler, another task requests the current 
task to carry out task exception handling. In such a case, if 
the exception handling request flag of the task is ON when the 
exception handling request flag returns from the exception handler 

10 (step S906) , the procedure returns to step S902, wherein task 
exception handling is again carried out (step S906) . Otherwise, 
the procedure goes to steps S907 and S908, and then the exception 
handling thread suspends itself (step S909) . The processing from 
steps S907 through S909 is the same as that from steps S303 through 

15 S305 shown in the flowchart of FIG. 5, and therefore is not described 
herein. After step S909, the changer thread runs, and if the 
charger thread resumes the exception handling thread, the procedure 
goes to step S902, and the task exception handling starts. 
[0085] As such, in the real-time OS simulator 40, if a request 

20 for task exception handling is issued to one task, the changer 
thread 41 resumes the exception handling thread of that task. The 
resumed exception handling thread calls the exception handler which 
was previously provided. Therefore, the real-time OS simulator 
40 can simulate the task exception handling of the real-time OS. 

25 Moreover, if the exception handler of one exception handling thread 
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is running when another thread runs, the changer thread 41 can 
resume the former exception handling thread. Therefore, the 
real-time OS simulator 40 can simulate the multi-level task 
exception handling. 
5 [0086] FIG. 23 is an exemplary timing chart of task exception 
handling by the real-time OS simulator 40, illustrating the states 
of eight threads (excluding interrupt threads 32 and 33) 
concurrently run on the real-time simulator 40 with the same 
notation as that used in FIG. 18. With reference to FIGS. 18 and 

10 23, while normal processing of one task is carried out in the real 
system, the task processing thread corresponding to that task runs 
in the real-time OS simulator 40 . While task exception processing 
of one task is carried out in the real system, on the other hand, 
the exception handling thread corresponding to that task runs in 

15 the real-time OS simulator 40. In the following description, 
assume that the first interrupt thread is a thread corresponding 
to an interrupt that is inputted by the user. 

[0087] In an initial state, assume herein that the first task 
processing thread and the first interrupt thread are suspended 

20 in the waiting state for an input from the user, and the first 
exception handling thread is suspended in step S909. Also assume 
herein that the second and third task processing threads and the 
second and third exception handling threads do not exist . Further 
assume that the exception handling flags of the tasks are all ON, 

25 and a higher priority is given to the first task, a lower priority 



is given to the second task, and an even lower priority is given 
to the third task. 

[0088] When the user provides an instruction input for starting 
processing at the time tl, the first interrupt thread monitoring 
5 a user's input runs. The first interrupt thread gives, in the 
interrupt handling (step S405) , an instruction for starting 
processing by using the system function. Thus, the first task 
processing thread which is suspended in the waiting state for an 
input from the user enters the runnable state. Then, the first 

10 interrupt thread returns from the interrupt handler so as to resume 
the first task processing thread (step S411) , and then is suspended 
again in the waiting state for an input from the user. 
[0089] When resumed after the time tl, the first task processing 
thread calls the system function for creating the second task. 

15 Thus, the second task processing thread and the second exception 
handling thread are created, where the former enters the runnable 
state and the latter is suspended in step S901. The second task 
is given a lower priority than the first task, and therefore, the 
first task processing thread continues to run. Then, the first 

20 task processing thread is suspended at the time t2 in the waiting 
state for an input from the user. After the first task is suspended, 
the task to run next is the second task. 

[0090] The changer thread detects, at the time t2, that the 
exception handling state flag and the exception handling request 
25 flag of the second task are both OFF (steps S805, S806) . Then, 



the changer thread selects the second task processing thread as 
the thread to run next (step S8 07) . The changer thread resumes 
the second task processing thread (step S810) , and then enters 
the waiting state for the first event (step S802). 
[0091] When resumed at the time t2, the second task processing 
thread calls the system function for creating the third task. Thus, 
the third task processing thread and the third exception handling 
thread are created, where the former enters the runnable state 
and the latter is suspended in step S901. The third task is given 
a lower priority than the second task, and therefore, the second 
task processing thread continues to run. Then, the second task 
processing thread is suspended at the time t3 until the third task 
exits or an instruction for canceling processing is provided. 
After the second task is suspended, the task to run next is the 
third task. 

[0092] The changer thread detects, at the time t3, that the 
exception handling state flag and the exception handling request 
flag of the third task are both OFF (steps S805, S806) . Then, 
the changer thread selects the third task processing thread as 
the thread to run next (step S807) . The changer thread resumes 
the third task processing thread (step S810) , and then enters the 
waiting state for the first event (step S802) . 
[0093] After the time t3, the third task processing thread 
carries out predetermined processing. An instruction which is 
input for canceling processing is provided by the user at the time 



t4, and the first interrupt thread monitoring an input from the 
user runs. The first interrupt thread gives, in the interrupt 
handler (step S405), an instruction for canceling processing by 
using the system function . Thus, the first task processing thread 
5 which is suspended in the waiting state for an input from the user 
enters the runnable state. The first task is given the highest 
priority, and therefore, the task to run next is the first task. 
[0094] Then, the first interrupt thread returns from the 
interrupt handler, determining that the delayed dispatch 
10 processing is required (step S407) . Based on the determination, 
the first interrupt thread resumes the first task processing thread 
(step S409) , and is suspended in the waiting state for an input 
from the user. 

[0095] When resumed after the time t4 , the first task processing 
15 thread gives an instruction for canceling processing to the second 
task processing thread. Thus, the second task processing thread 
enters the runnable state. The second task is given a lower 
priority than the first task, and therefore, the first task 
processing thread continues to run. Then, the first task 
20 processing thread requests, by using the system function, the 
second task to carry out task exception handling. Thus, the 
exception handling request flag of the second task is set ON . Then, 
at the time t5, the first task processing thread is suspended in 
the waiting state for the second task to exit. After the first 
25 task is suspended, the task to run next is the second task. 



[0096] The changer thread detects, at the time t5, that the 
exception handling request flag of the second task is ON (step 
S806) , and selects the second exception handling thread as the 
next running thread (step S808) . The changer thread then resumes 
the second exception handling thread (step S810) , and then enters 
the waiting state for the first event (step S802) . 

[0097] When resumed at the time t5, the second exception 
handling thread sets its own exception handling state flag ON (step 

5902) , and sets its own exception handling request flag OFF (step 

5903) . The second exception handling thread then calls its own 
exception handler (step S904) . In this exception handler, the 
second exception handling thread requests, by using the system 
function, the third task to carry out task exception handling. 
Thus, the exception handling request flag of the third task is 
set ON. Then, at the time t6, the second exception handling thread 
is suspended in the waiting state for the third task to exit. When 
the second task is suspended, the task to run next is the third 
task. 

[0098] The changer thread detects, at the time t6, that the 
exception handling request of the third task is ON (step S806) , 
and selects the third exception handling thread as the next running 
thread (stepS808) . The changer thread resumes the third exception 
handling thread (step S810), and then enters the waiting state 
for the first event (step S802) . 

[0099] When resumed at the time t6, the third exception handling 



thread sets its own exception handling state flag ON (step S902) , 
and sets its own exception handling request flag OFF (step S903) . 
The third exception handling thread then calls its own exception 
handler (step S904) . In this exception handler, the third 
5 exception handling thread carries out processing such as a 
deallocation of the memory area, and then calls the system function 
for suspending its own task. Thus, the second task which is 
suspended in the waiting state for the third task to exit enters 
the runnable state. Then, the third exception handling thread 
10 suspends itself in this system function (step S305) . At the time 
t7, the task to run next is the second task. 

[0100] The changer thread detects, at the time t7, that the 
exception handling state flag of the second task is still ON (step 
S805) , and selects the second exception handling thread again as 

15 the next running thread (step S808) . The changer thread resumes 
the second exception handling thread (step S810) , and then enters 
the waiting state for the first event (step S802) . 
[0101] When resumed at the time t7, the second exception 
handling thread calls, in the exception handler, the system 

20 function for making its own task exit. Thus, the first task which 
is suspended in the waiting state for the second task to exit enters 
the runnable state. Then, the second exception handling thread 
suspends itself in this system function (step S305) . At the time 
t8, the task to run next is the first task. 

25 [0102] The changer thread detects, at the time t8, that the 



exception handling state flag and the exception handling request 
flag of the first task are both OFF (steps S805, S806) , and selects 
the first task processing thread as the next running thread (step 
S8 07 ) . The changer thread resumes the first task processing thread 
5 (step S810) , and then enters the waiting state for the first event 
(steps S802) . Then, the first task processing thread is again 
suspended in the waiting state for an input from the user. 
[0103] As stated above, in the real-time OS simulator according 
to the third embodiment, one task processing thread and one 

10 exception handling thread are assigned to each task in the real 
system. The changer thread selects one of these two threads to 
run next . The task processing thread requests , by using the system 
function, another task to carry out task exception handling. The 
exception handling thread calls the exception handler for the 

15 requested task. Thus, the real-time OS simulator according to 
the third embodiment can simulate the task exception handling of 
the real-time OS. 

[0104] In the third embodiment, two threads are previously 
created for each task. Alternatively, two threads may be created 

20 only for a task that executes task exception handling. As another 
alternative, the exception handling thread may be dynamically 
created when task exception handling actually runs. As such, by 
reducing the number of threads concurrently running on the 
general-purpose OS, the real-time OS simulator can operate more 

25 rapidly. 



[0105] In the real-time OS simulators according to the first 
through third embodiments , the real-time OS and the general-purpose 
OS are not limited to specific OSes. Also, the real-time OS 
simulator may realize synchronization between threads by using 
5 capabilities except for the event capability that is provided by 
the general -purpose OS . Still further, the task processing thread 
and the interrupt thread may be both created by the real-time OS 
simulator or by any other component outside of (external to) the 
real-time OS simulator, 
10 [0106] While thepresent invention has been described in detail , 
the foregoing description is in all aspects illustrative and not 
restrictive. It is understood that numerous other modifications 
and variations can be devised without departing from the scope 
of the present invention. 
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